【アップデート】Timestreamでクエリをスケジュール実行できるようになりました #reinvent
【アップデート】Timestreamでクエリをスケジュール実行できるようになりました #reinvent
MAD事業部@大阪の岩田です。先日のアップデートによってTimestreamに3つの新機能が追加されました。
本エントリではそのうちの1つであるScheduled Queryについてご紹介します
概要
Scheduled Queryはその名の通りクエリをスケジュール実行する機能です。設定されたスケジュールに沿ってクエリを実行し、実行結果をTimestreamのテーブルに書き込むことができます。Scheduled Queryは以下のような設定項目を持ちます
スケジュール
クエリを定期実行するスケジュールを指定します。EventBridge等と同様に書式として
- cron式
- rate式
の2種がサポートされています。
クエリストリング
定期実行するクエリを指定します。通常のクエリとの違いは @scheduled_runtimeというパラメータが利用できる点です。このパラメータにはクエリ実行時のタイムスタンプが設定されます。WHERE句に@scheduled_runtimeを指定するのがメインの使い方になるでしょう。
ターゲット
クエリの実行結果を書き込むTimestreamのデータベース、テーブルを指定します。さらに、Data Model Mappingsという設定項目によってクエリの実行結果を書き込み先のテーブルにどのようにマッピングするかが指定できます。
- メジャーとして登録するか、ディメンションとして登録するか？
- メジャーのデータの型
- メジャーの名前
といった項目が指定できます
通知設定
クエリの定期実行や手動実行といったイベントを通知するSNSトピックを指定します
エラーレポート
Scheduled Queryが失敗した際に、エラーレポートを出力するためのS3バケットとプレフィックスを指定します。S3バケットはTimestreamと同一リージョンに作成する必要があることに注意が必要です。
IAMロール
Scheduled Queryを実行する際に利用するIAMロールを指定します。
やってみる
実際にScheduled Queryを試してみます。今回はTimestreamのサンプルテーブルとして提供されているDevOpsテーブルに対して以下のクエリを定期実行してみます。
SELECT
region,
az,
hostname,
BIN(time, 1h) AS binned_timestamp,
ROUND(AVG(measure_value::double), 2) AS avg_cpu_utilization,
ROUND(APPROX_PERCENTILE(measure_value::double, 0.9), 2) AS p90_cpu_utilization,
ROUND(APPROX_PERCENTILE(measure_value::double, 0.95), 2) AS p95_cpu_utilization,
ROUND(APPROX_PERCENTILE(measure_value::double, 0.99), 2) AS p99_cpu_utilization
FROM
"sampledb".DevOps
WHERE
measure_name = 'cpu_utilization'
AND time BETWEEN bin(@scheduled_runtime, 1h) - 14h AND bin(@scheduled_runtime, 1h) - 2h
GROUP BY
region,
hostname,
az,
BIN(time, 1h)
ORDER BY
binned_timestamp ASC
IAMロールの作成
ざっとドキュメントを見たのですが、現時点ではIAMロールに必要な権限など特に記載が無いようです。ちょっと過剰ですが、以下のポリシーをアタッチしました
- AmazonS3FullAccess
- AmazonSNSFullAccess
- AmazonTimestreamFullAccess
信頼ポリシーはこちら
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "timestream.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
SNSトピックの作成
通知設定で使用するためのSNSトピックも事前に作成しておきます。特に変わった設定は不要なので、設定値はデフォルトのままでサクッと作成しましょう。トピックを作成したら自分のEメールアドレスでサブスクリプションの設定まで完了しておきます。
S3バケットの作成
エラーレポート書き込み先のS3バケットを作成します。Timestreamと同じリージョンに作成する必要があるので注意です。
DBとテーブルの用意
TimestreamのマネコンからサンプルDBとテーブルを作成します。サンプルデータのDevOpsにチェックを入れて「Create Database」をクリックしましょう
続いて書き込み先のテーブルも作成しておきます。書き込み先のテーブルには別データベースのテーブルも指定できますが、今回は同一データベース内に作成します。DevOpsAggという名前でsampledb内にテーブルを作成します。
Scheduled Queryの作成
準備ができたのでScheduled Queryを作成していきます。まずはターゲットのテーブルとクエリの名前を指定
続いてクエリストリングを指定します
Data Model Mappingsを指定します。
- region
- az
- hostname
をDimensionに指定し、その他のカラムはデフォルトのまま進めます
続いてスケジュールの指定です。今回はrate式を使って5分毎に定期実行する設定としました
※クエリが1時間単位の集計なので整合性が取れていないですが、検証目的なので短めのスパンに設定しています
通知先のSNSトピックとエラーレポート出力先のS3バケット&プレフィックスを指定します
設定内容を確認して作成を完了します
これで5分ごとにクエリがスケジュール実行されるはずです。
Scheduled Queryの実行結果確認
しばらく待ってからScheduled Queryの実行結果を確認してみます。まずSNSの通知をメールに届いていることを確認します。こんな感じでAUTO_TRIGGER_SUCCESSの通知がきています。
{"type":"AUTO_TRIGGER_SUCCESS","arn":"arn:aws:timestream:us-east-1:123456789012:scheduled-query/query_cpu_utilization_agg-657c071ea5e7e648","nextInvocationEpochSecond":1638423484,"scheduledQueryRunSummary":{"invocationEpochSecond":1638423184,"triggerTimeMillis":1638423184727,"runStatus":"AUTO_TRIGGER_SUCCESS","executionStats":{"executionTimeInMillis":11068,"dataWrites":30720,"bytesMetered":10000000,"recordsIngested":267,"queryResultRows":267}}}
If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe:
https://sns.us-east-1.amazonaws.com/unsubscribe.html?SubscriptionArn=....略
Please do not reply directly to this email. If you have any questions or comments regarding this email, please contact us at https://aws.amazon.com/support
続いてマネコンを確認します
Last run summaryに直近の実行履歴が表示されています
最後にクエリエディタからクエリを発行しScheduled Queryのターゲットに指定したテーブルの中身を確認します。
集計結果のレコードが投入されていることが分かります
まとめ
TimestreamのScheduled Queryについてご紹介しました。Scheduled Queryを使って事前に集計済みのデータを作成すると、毎回集計クエリを実行するのと比較してレスポンスの速度やクエリの従量課金といった面でメリットが出せます。BIツールからTimestreamのデータを参照するようなユースケースでうまく活用していきたいですね。
